IBIS Macromodel Task Group Meeting date: 14 March 2023 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora Systems: * Dian Yang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater * Ming Yan Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): Walter Katz Mike LaBonte Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Yifan Ding Rivos Yansheng Wang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Waymo: Zhiping Yang Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Randy said the Quality task group had an update on the AMI root name checking topic, time permitting (see below). ------------- Review of ARs: Stephen: Socialize the SPIM proposal/BIRD with experts in the field and gather their feedback. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 7th meeting. Kinger moved to approve the minutes. Dian seconded the motion. There were no objections. -------------- New Discussion: PSIJ Sensitivity BIRD draft: Kinger said he had received no new feedback on draft8. He reviewed the changes contained in draft8 (see minutes from March 7th, 2023). Kinger and Arpad noted that references to [Device SPIM Group] in draft8 were premature and should be removed, as the SPIM BIRD had not yet been approved. Kinger said he would remove references to [Device SPIM Group], but he and Arpad said this minor editorial change was not sufficient to require a new draft to be sent out. Randy asked whether we need a way to define which signal pins are affected by the PSIJ. How would the user know what buffers are affected by the jitter distribution that is computed with the help of these new keywords? Kinger said this proposal is holistically looking at the final jitter distribution that would be applied to the final Rx eye diagram. If it were for a clock forwarded architecture such as DDR5, then it would include the cumulative effects on the data channel signal and the clock signals, for example. The jitter computed using the [PSIJ Sensitivity] data and the noise spectral density of the power rail(s) would be applied to the final eye. Randy noted that we have the [Clock Pins] keyword in IBIS. While it's not related to this topic directly, it establishes a precedent for having a list of pins that are somehow related. Randy wondered whether we need an additional keyword with this proposal to define the list of signal pins that are affected by the jitter computed using the [PSIJ Sensitivity] information. Randy and Arpad then discussed whether the rail names from [PSIJ Voltage List] could be mapped back to individual buffers via the [Pin Mapping] keyword, but they said we need to think about this carefully. Randy asked whether this jitter is something the tool would add in during post processing or whether it would be a jitter input to an AMI model. Kinger said the tool could perform a noiseless SI simulation and then add this total jitter in as a post processing step. Arpad said this was an interesting question. He noted that AMI defines Reserved jitter parameters that are applied to the Tx stimulus waveform. If the jitter contributions affecting the blocks included in the Tx AMI model were applied to the stimulus waveform, then the behavior of the models might be affected (filter adaptations, etc.), and spectral filtering by the channel would occur, and the overall results might be quite different than those obtained by adding everything in via post processing of the Rx final eye. Ambrish asked what distributions were being considered here Gaussian, random, etc. Kinger said this BIRD does not determine the distribution. The user or tool define a simulation that determines the power noise on the rail(s). The [PSIJ Sensitivity] information then allows the tool to map the noise spectral density to a jitter distribution. Kinger said determining the noise profile may be complicated. There may be many power modes to consider, sleeping, waking up, etc., and you would want to capture all of the possible activities in your noise profile. Arpad said this proposal aims to combine a noiseless signal simulation with a signalless power simulation. Kinger agreed. Ambrish asked whether this proposal was defining a new methodology. Arpad said he agreed with comments from Walter in a recent meeting that the specification should define the data that is made available, but it should not define flows. Ambrish noted that some flows are defined, AMI itself, for example. Wei-hsing said that if two simulators come up with very different results using the same data, then questions will come back to this group. Dian returned to Randy's original question and asked whether we need to add information about which signal pins are impacted by the jitter. Kinger said he didn't think so. He referred to Arpad and Randy's previous comments about the possibility of mapping back to signal pins using [PSIJ Voltage List] rail names and the [Pin Mapping] keyword. Randy suggested that we think about this more. Dian presented an HDMI scenario. He said it has a clock signal and data signals, and perhaps certain power rails only affect the clock and others only affect the data. Kinger said eventually you want to get the final eye at the Rx, and all the clock and data jitter variations would be included. He said this proposal doesn't necessarily want to separate out individual contributions and handle data and clock eye diagrams individually. Quality Task Group question/update, BUG 227 - AMI root name check: Randy reported that the Quality task group had decided not to address BUG227 at the present time. They do not want to hold up the development of ibischk7.2. In order for the parser to confirm that the executable model returned the same root name found in the .ami file, the parser would have to call AMI_Init(). At present, there is no way to guarantee that the parser could come up with valid input to AMI_Init() for any given model. There are many cases in which models' AMI_Init() functions will fail or crash with bad input data. Randy noted that IBIS 7.2 had at least clarified the requirement that the root name returned by the model must match that in the .ami file. However, there is nothing the parser can do to test or enforce that requirement at the current time. Arpad suggested that one solution might be to add a new AMI Reserved parameter. If the model advertised this parameter, and the tool passed in the right value, the model would operate in a type of test mode and only return the root name. In this scenario, AMI_Init() would not look at all the other inputs. Michael asked whether having [AMI Test Load] and [AMI Test Data] would solve the problem. He said that if a they were defined, then the parser would be sure that it could provide valid input when calling AMI_Init(). Michael said he would have a proposal for [AMI Test Load] and [AMI Test Data] within the next few months. Arpad said that a simple Reserved parameter might be easier for the model maker and might encourage faster adoption. He then noted that his proposal might not be so simple if we ever plan to support multiple root names (multiple parameter trees) in one .ami file. Would the Reserved parameter have to return a list of the valid root names? Bob said we don't support different root names in a .ami file. Michael and Arpad said we might consider doing so in the future and using them as a sort of model selector. Ambrish said it would be more helpful if the model simply complained when it didn't like the root name it received in AMI_parameters_in. Arpad asked whether this needed further discussion. Michael recommended that we defer discussion until he has an [AMI Test Load]/[AMI Test Data] proposal ready. He said that we need that data anyway, and it will then make this parser check possible. - Curtis: Motion to adjourn. - Kinger: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 21 March 2023 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives